[세션 레포트] 천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기 #AWSSummitOnlineKorea

AWS Summit Online Korea에서 발표된 '천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기' 세션의 레포트입니다. AWS의 인프라적 장점에 대해서 소개하시며, 사용자 수에 따라 어떻게 아키텍처를 구축하고 어떤 서비스를 이용하면 좋은지에 대해 다루어주셨어요.

AWS Summit Online Korea 2020

#レポート

#한국어블로그

Haeun

2020.05.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요! 클래스메소드 주식회사 신입엔지니어 정하은입니다?

어제는 AWS Summit Online Korea가 개최되었죠! 저희 회사 한국 멤버들도 모두 참여하여 여러분들께 세션 정보를 전해드리고자 블로그로 세션 레포트를 작성하게 되었어요. 사실 저는 AWS 관련 행사 참여는 처음이기도 하고 초심자이다보니 내용들을 이해할 수 있을까 걱정도 많았는데요.. 하지만 입문자를 위한 세션도 마련되어 있고, 반복해서 볼 수 있었기 때문에 그런 걱정 없이 유익한 시간이 되었습니다?

혹시라도 어제 신청을 놓치신 분들이라도 https://aws.amazon.com/ko/events/summits/online/korea/ 들어가셔서 등록하시면 8월말까지 시청이 가능하다고 합니다. 단, AWSomeday는 5월 24일까지만 열리니 AWS 초보자분들께는 서둘러 들어놓으시는 걸 추천드려요!

이번 글에서는 모범 사례의 '천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기' 세션에 대해 정리해보겠습니다!

발표자 소개

문종민 님

솔루션즈 아키텍트
AWS Korea

AWS 글로벌 인프라스트럭처와 서비스

AWS는 전세계 22개의 리전이 존재
각 리전마다 2개 이상의 가용 영역을 지니고 있어 타 서비스보다 가용성이 높음
리전들과 216개의 PoP(엣지 로케이션 205개, 리전 엣지 캐시 11개)은 backbone 네트워크로 연결되어 있어 낮은 latency를 가짐
컴퓨팅 스토리지, 네트워크, 데이터베이스와 같은 핵심 분야 뿐만 아니라 머신러닝, 빅데이터, IOT, DevOps, 모바일, 온프레미스와 클라우드의 하이브리드 서비스, 보안 서비스 등 175가지 이상의 서비스 제공

사용자 증가에 따른 아키텍처 진화

이 파트에서는 사용자 수에 맞춰 아키텍처 설계 예시와 사용되는 AWS 서비스에 대해 설명해주셨습니다!

사용자수 < 1,000

서버 선정 → EC2
- 업무에 적합하고, 필요 성능(IOPS)에 맞는 스토리지 선택
- 온프레미스와 달리 인스턴스 타입 변경이 쉽기 때문에 용량 산정에 대한 고민이 불필요함
- 241가지의 인스턴스 타입으로 대부분의 워크로드 및 비즈니스 요구에 적용 가능

서버 이중화 구성 → VPC
- 리전 내 서로 다른 가용 영역에 인스턴스를 생성함으로써 더 높은 가용성 확보

요청 분산 → AWS Elastic Load Balancing(ELB)

※ ALB VS NLB

고가용성, 자동 확장을 해준다는 공통점이 있으나, ALB는 HTTP/HTTPS 를 지원하며 컨텐츠 기반 라우팅 시 사용되고, NLB는 TCP/UDP/TLS 를 지원하며 고정 IP로 인해 도메인 사용이 불가능 할 시에 유용함

DB 구성 → Amazon RDS
- Amazon Aurora, MySQL, PostgreSQL, MariaDB, SQL Server, ORACLE 중 원하는 데이터베이스를 별도 설치없이 사용 가능

※ Amazon Aurora

MySQL, PostgreSQL 호환

3개의 가용 영역에 6벌 복제, 최대 15개 읽기 복제본

자동 스트리지 확장 및 백업

사용자 인증 서비스 구현 → Amazon Cognito
- UI 내장
- 구글, 페이스북 등의 계정과 연동 가능

소스코드 관리 및 배포 → AWS Code 서비스
- AWS Cloud9 : 개발
- AWS CodeCommit : 형상관리
- AWS CodeBuild : 빌드
- Third-party tooling : 테스트
- AWS CodeDeploy : 배포
- AWS CodePipeline : 위의 모든 과정을 통합

사용자수 > 1,000

시스템 확장 → EC2 오토 스케일링
- 갑자기 접속 수가 많아지는 경우를 고려해 규칙을 정해두면 EC2 수량을 자동으로 조절
- 최소 수량을 설정해두면 특정 임계치에 도달 시 설정 수량만큼 기동

DB 가용성 확보 → Amazon RDS 다중 AZ 배포
- 한 가용영역에 Master, 다른 가용영역에 Stand by 생성
- Master의 데이터를 Stand by에 복제 후 동기화
- Master 장애 시, Stand by를 Master로 자동 승격하여 대체

백업 관리 → AWS Backup
- 백업 데이터 수명 관리 정책을 설정하여 자동 백업
- AWS Storage Gateway 서비스와 함께 사용시, 온프레미스 데이터를 AWS로 백업
- 백업 데이터 암호화

모니터링 → CloudWatch
- AWS 서비스별 주요 지표 데이터 수집
- 조건에 따른 Alarm 수행
- 여러 리전에 구성된 리소스들을 Dashboard를 통해 단일 모니터링 뷰로 확인

사용자수 > 10,000

성능 향상 → Amazon CloudFront

사용자가 리소스 요청을 보낼 시, 사용자와 가까운 PoP에 먼저 전달
캐시에 저장해두어 동일한 리소스 요청이 올 경우, 캐시에 둔 데이터로 직접 응답
오리진 측 부하 감소 및 엔드 유저 latency 감소

부하 분산 → RDS

※ Amazon Aurora 읽기 복제본 오토스케일링

읽기 복제본을 사용하여 평균 CPU 사용률, 평균 커넥션 수를 기준으로 오토 스케일링 되도록 구성

단일 END-POINT로 제공 되기 때문에 읽기 복제본이 여러 개라도 어플리케이션 분산에 대한 문제 해결

Amazon ElastiCache

캐시 클러스터를 쉽게 구성할 수 있도록 해주는 서비스
1밀리초 미만의 응답 속도와 다양한 Usecase에서 활용 가능한 이점이 있음
빈번하게 액세스하는 데이터의 경우, DB보다 캐시 서버를 구성해 더 빠른 응답이 필요
EC2 오토스케일링을 적용할 경우, HTTP 세션 데이터를 개별 EC2 메모리에 저장하는 것보다는 캐시 서버를 따로 구성하는 것이 나음

사용자수 > 100,000

Loosely Coupled → Amazon SQS, Amazon SNS
- SQS는 producer가 메시지를 큐에 넣으면 consumer가 pull방식으로 꺼내오는 서비스
- SNS는 producer가 토픽에 메시지를 게시하면 해당 토픽을 구독하는 여러 대상으로 SNS가 푸시 방식으로 전달

서버리스, 이벤트 기반 아키텍처 → AWS Lambda
- 서버를 미리 프로비저닝하거나 관리하지 않더라도 요청에 따라 리소스가 자동적으로 스케일링

분산 아키텍처

- 용도에 맞는 DB 서비스 사용
- 특정 데이터를 Data warehouse에 넣어 분석해야 할 때, 서버 A에서 put 하면 서버 B에서 꺼내 Redshift로 적재
- 사용자가 DynamoDB에서 데이터를 조회할 경우, API Gateway에서 요청해 Lambda에서 분산 처리